Network Working Group Y. Bernet 

Request for Comments: 2996 Microsoft 

Category: Standards Track November 2000 
Format of the RSVP DCLASS Object 


Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2000). All Rights Reserved. 
Abstract 


Resource Reservation Protocol (RSVP) signaling may be used to request 
Quality of Service (QoS) services and enhance the manageability of 
application traffic’s QoS in a differentiated service (diff-serv or 
DS) network. When using RSVP with DS networks it is useful to be 
able to carry carry Differentiated Services Code Points (DSCPs) in 
RSVP message objects. One example of this is the use of RSVP to 
arrange for the marking of packets with a particular DSCP upstream 
from the DS network’s ingress point, at the sender or at a previous 
network’s egress router. 


The DCLASS object is used to represent and carry DSCPs within RSVP 
messages. This document specifies the format of the DCLASS object 
and briefly discusses its use. 


1. Introduction 


This section describes the mechanics of using RSVP [RSVP] signaling 
and the DCLASS object for effecting admission control and applying 
QoS policy within a Differentiated Service network [DS]. It assumes 
standard RSVP senders and receivers, and a diff-serv network 
somewhere in the path between sender and receiver. At least one RSVP 
aware network element resides in the diff-serv network. This network 
element may be a policy enforcement point (PEP) [RAP] or may simply 
act as an admission control agent for the network, admitting or 
denying resource requests based on the availability of resources. In 
either case, this network element interacts with RSVP messages 
arriving from outside the DS network, accepting resource requests 
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from RSVP-aware senders and receivers, and conveying the DS network’s 
admission control and resource allocation decisions to the higher- 
level RSVP. The network element is typically a router and will be 
considered to be so for the purpose of this document. This model is 
described fully in [INTDIFF]. 


1.1 Use of the DCLASS Object to Carry Upstream Packet Marking 
Information 


A principal usage of the DCLASS object is to carry DSCP information 
between a DS network and upstream nodes that may wish to mark packets 
with DSCP values. Briefly, the sender composes a standard RSVP PATH 
message and sends it towards the receiver. At some point the PATH 
message reaches the DS network. The PATH message traverses one or 
more network elements that are PEPs and/or admission control agents 
for the diff-serv network. These elements install appropriate state 
and forward the PATH message towards the receiver. If admission 
control is successful downstream of the diff-serv network, then a 
RESV message will arrive from the direction of the receiver. As this 
message arrives at the PEPs and/or admission control agents that are 
RSVP enabled, each of these network elements must make a decision 
regarding the admissibility of the signaled flow to the diff-serv 
network. 


If the network element determines that the request represented by the 
PATH and RESV messages is admissible to the diff-serv network, the 
appropriate diff-serv service level (or behavior aggregate) for the 
traffic represented in the RSVP request is determined. Next, a 
decision is made to mark arriving data packets for this traffic 
locally using MF classification, or to request upstream marking of 
the packets with the appropriate DSCP(s). This upstream marking 
could occur anywhere before the DS network’s ingress point. Two 
likely candidates are the originating sender and the egress boundary 
router of some upstream (DS or non-DS) network. The decision about 
where the RSVP request’s packets should be marked can be made by 
agreement or through a negotiation protocol; the details are outside 
the scope of this document. 


If the packets for this RSVP request are to be marked upstream, 
information about the DSCP (s) to use must be conveyed from the RSVP- 
aware network element to the upstream marking point. This 
information is conveyed with the DCLASS object. To do this, the 
network element adds a DCLASS object containing one or more DSCPs 
corresponding to the behavior aggregate, to the RESV message. The 
RESV message is then sent upstream towards the RSVP sender. 


If the network element determines that the RSVP request is not 
admissible to the diff-serv network, it sends a RESV error message 
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towards the receiver. No DCLASS is required. 
1.1 Additional Uses of the DCLASS Object 


The DCLASS object is intended to be a general tool for conveying DSCP 
information in RSVP messages. This may be useful in a number of 
situations. We give one further example here as motivation. 


In this example, we assume that the decision about the appropriate 
behavior aggregate for a RSVP-mediated traffic flow is made at the DS 
network egress router (or a related Policy Decision Point) by 
observing RSVP PATH and RESV messages and other necessary 
information. However, the actual packet marking must be done at the 
ingress of the network. The DCLASS object can be used to carry the 
needed marking information between egress and ingress routers. 


2. Format of the DCLASS Object 


The DCLASS object has the following format: 


0 | 1 | 2 | 3 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +++ 
| Length (>= 8) |  C-Num (225) | 1 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +++ 
| Unused | 1st DSCP | | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +++ 
| Unused | 2nd DscP | | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +++ 
| Unused |. iid edie A | | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +++ 


The first word contains the standard RSVP object header (the Class 
Num for the DCLASS object is 225). The length field indicates the 
total object length in bytes. The object header is followed by one 
or more 32-bit words, each containing a DSCP in the six high-order 
bits of the least significant byte. The length field in the object 
header indicates the number of DSCPs included in the object. 
Specifically, the number of DCLASS objects present is equal to 
(Length - 4) / 4. 


The network may return multiple DSCPs in the DCLASS object in order 
to enable the host to discriminate sub-flows within a behavior 
aggregate. For example, in the case of the AF PHB group [AF], the 
network may return the DSCPs 001010, 001100, and 001110 corresponding 
to increasing levels of drop precedence within Class 1 of the AF PHB 
group. Note that this document makes no statements regarding the 
significance of the order of the returned DSCPs. Further 
interpretation of DSCP sets is dependent on the specific service 
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requested by the host and is beyond the scope of this document. 


Note that the Class-Num for the DCLASS object is chosen from the 
space of unknown class objects that should be ignored and forwarded 
by nodes that do not recognize it. This is to assure maximal 
backward compatibility. 


3. Admission Control Functionality 


From a black-box perspective, admission control and policy 
functionality amounts to the decision whether to accept or reject a 
request and the determination of the DSCPs that should be used for 
the corresponding traffic. The specific details of admission control 
are beyond the scope of this document. In general the admission 
control decision is based both on resource availability and on 
policies regarding the use of resources in the diff-serv network. 

The admission control decision made by RSVP aware network elements 
represents both considerations. 


In order to decide whether the RSVP request is admissible in terms of 
resource availability, one or more network elements within or at the 
boundary of the diff-serv network must understand the impact that 
admission would have on specific diff-serv resources, as well as the 
availability of these resources along the relevant data path in the 
diff-serv network. 


In order to decide whether the RSVP request is admissible in terms of 
policy, the network element may use identity objects describing users 
and/or applications that may be included in the request. The router 
may act as a PEP/PDP and use data from a policy database or directory 
to aid in this decision. 


See Appendix A for a simple mechanism for configurable resource based 
admission control. 


4. Security Considerations 


The DCLASS object conveys information that can be used to request 
enhanced QoS from a DS network, so inappropriate modification of the 
object could allow traffic flows to obtain a higher or lower level of 
QoS than appropriate. Particularly, modification of a DCLASS object 
by a third party inserted between the DS network ingress node and the 
upstream marker constitutes a possible denial of service attack. 

This attack is subtle because it is possible to reduce the received 
QoS to an unacceptably low level without completely cutting off data 
flow, making the attack harder to detect. 


The possibility of raising the received level of QoS by inappropriate 


Bernet Standards Track [Page 4] 


RFC 2996 Format of the RSVP DCLASS Object November 2000 


modification of the DCLASS object is less significant because it a 
subclass of a larger class of attacks that must already be detected 
by the system. Protection must already be in place to prevent a host 
raising its received level of QoS by simply guessing "good" DSCP’s 
and marking packets accordingly. If this protection is at the 
boundary of the DS network, it will detect inappropriate marking of 
arriving packets caused by modified DCLASS objects as well. If, 
however, the protection function as well as the marking function has 
been pushed upstream (perhaps to a trusted third party or 
intermediate node), correct transmission of the DCLASS object must be 
ensured to prevent a possible theft of service attack. 


Simple observation of the DCLASS object in a RSVP message raises 
several issues which may be seen as security concerns. Correlation 
of observed DCLASS object values with RSVP requests or MF 
classification parameters allows the observer to determine that 
different flows are receiving different levels of QoS, which may be 
knowledge that should be protected in some environments. Similarly, 
observation of the DCLASS object can allow the observer to determine 
that a single flow’s QoS has been promoted or demoted, which may 
signal significant events in the life of that flow’s application or 
user. Finally, observation of the DCLASS object may reveal 
information about the internal operations of a DS network that could 
be useful to observers interested in theft-of-services attacks. 
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Appendix A - Simple Configurable Resource Based Admission Control 


Routers may use quite sophisticated mechanisms in making the 
admission control decision, including policy considerations, various 
intra-domain signaling protocols, results of traffic monitoring and 
so on. It is recommended that the following basic functionality be 
provided to enable simple resource based admission control in the 
absence of more sophisticated mechanisms. This functionality can be 
used with configurable, standalone routers. It applies to standard 
RSVP/Intserv requests. This minimal functionality assumes only a 
single DSCP is included in the DCLASS object, but may readily be 
extended to support multiple DSCPs. 


It must be possible to configure two tables in the router. These are 
described below. 


A.1 Service Type to DSCP Mapping 


One table provides a mapping from the intserv service-type specified 
in the RSVP request to a DSCP that can be used to obtain a 
corresponding service in the diff-serv network. This table contains 
a row for each intserv service type for which a mapping is available. 
Each row has the following format: 


Intserv service type : DSCP 


The table would typically contain at least three rows; one for 
Guaranteed service, one for Controlled Load service and one for Best- 
Effort service. (The best-effort service will typically map to DSCP 
000000, but may be overridden). It should be possible to add rows 
for as-yet-undefined service types. 


This table allows the network administrator to statically configure a 
DSCP that the router will return in the DCLASS object for an admitted 
RSVP request. In general, more sophisticated and likely more dynamic 
mechanisms may be used to determine the DSCP to be returned in the 
DCLASS object. Also, it is likely that a real mapping for some 
services would use more than one DSCP, with the DSCP depending on the 
invocation parameters of a specific service request. In this case, 
these mechanisms may override or replace the static table based 
mapping described here. 


A.2 Quantitative Resource Availability 
Standard intserv requests are quantitative in nature. They include 
token bucket parameters describing the resources required by the 


traffic for which admission is requested. The second table enables 
the network administrator to statically configure quantitative 
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parameters to be used by the router when making an admission control 
decision for quantitative service requests. Each row in this table 
has the following form: 


DSCP : Token bucket profile 


The first column specifies those DSCPs for which quantitative 
admission control is applied. The second column specifies the token 
bucket parameters which represent the total resources available in 
the diff-serv network to accommodate traffic in the service class 
specified by the DSCP. 
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Full Copyright Statement 
Copyright (C) The Internet Society (2000). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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